Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Using launch.i or dynlaunch.i to run the PLIP

Next comes the key part of the exercise: running the business logic procedure that is located where the data is, which will return the needed Credit value. The standard Progress Dynamics include file, launch.i, takes a series of named arguments that is explained in OpenEdge Development: Progress Dynamics Basic Development . In this example, it runs the internal procedure AvailCredit in the persistent procedure customerplip.p, passing it the parameter list specified, deleting the running instance of customerplip.p when it is done, as shown:

{launch.i &PLIP = 'oe/customerplip.p' &IProc = 'AvailCredit' &PList = "(INPUT cKeyType, INPUT iKeyNum, OUTPUT dAvailCredit)" &AutoKill = YES &Perm = NO}

There is now a new alternative to launch.i that is more efficient in cases where you do not need to retain the procedure handle of the business logic procedure after your request has returned. This include file is dynlaunch.i, and it takes advantage of the dynamic CALL object to carry out the entire request in a single AppServer call, running code on the server that starts the PLIP if it is not already running, runs the requested internal procedure, passes in any INPUT parameters, receives back any OUTPUT parameters, and deletes the PLIP if it was started by the call.

The dynlaunch.i file uses essentially the same named arguments as launch.i, except that INPUT and OUTPUT parameters are expressed as named arguments rather than as a single quoted string. This is because the arguments are actually evaluated on the server dynamically using a CALL object to construct the call at run time. For each parameter to the internal procedure you are running, you must specify three named include file arguments. In each case, n represents the position of the parameter in the calling sequence:

Moden — INPUT, OUTPUT, or INPUT-OUTPUT.
&Parmn — The parameter name as a single-quoted string.
&DataTypen — The data type of the parameter as an unquoted string.

Also, because the handle of the server-side procedure cannot be made available to the client after the call is complete, the &AutoKill and &Perm arguments do not apply. A call to dynlaunch.i to accomplish the same request as the previous call to launch.i looks like this:

{dynlaunch.i &PLIP = 'oe/customerplip.p' &IProc = 'AvailCredit' &mode1 = INPUT &parm1=cKeyType &dataType1 = CHARACTER &mode2 = INPUT &parm2=iKeyNum &dataType2 = INTEGER &mode3 = OUTPUT &parm3=dAvailCredit &dataType3 = DECIMAL }

If you use dynlaunch.i, you must also include this reference in the Definitions section of your procedure so that the variables it uses are properly defined, as shown:

{dynlaunch.i &define-only=YES}

Next comes the standard error checking include file, checkerr.i, which is described in OpenEdge Development: Progress Dynamics Basic Development , as shown:

{checkerr.i &display-error = YES &return-only = YES}

These arguments mean that an error will be displayed if there is one (because the code is being executed on the client, where the error dialog box can be displayed). The code will return out of the procedure if there is an error, but will not pass a specific error condition to its caller.

The code locates the dynamic fill-in AvailCredit in the viewer, and sets its SCREEN-VALUE, as shown:

ASSIGN ilookup = LOOKUP("AvailCredit", cFieldNames) hField = WIDGET-HANDLE(ENTRY(ilookup, cFieldHandles)) hField:SCREEN-VALUE = STRING(dAvailCredit).